RabbitMQ 是一個開源的訊息代理軟體，它使用了高級訊息佇列協定(Advanced Message Queuing Protocol, AMQP)，Client端可透過此協定與RabbitMQ傳遞訊息且不受不同的應用程式、不同的開發語言等條件的限制。它也常被用於分散式系統架構中。

在RabbitMQ內包含幾個重要的角色：

1.生產者（Producer）， 即為訊息的產生者，會負責將訊息傳送至Queue中。

2.消費者（Consumer）， 訊息的消費者，負責接收Queue中的訊息。

3.訊息佇列（Queue）， 負責存放訊息的空間，具有先進先出（FIFO）的概念。

4.交換器（Exchange）， 可以把Exchange當作路由器的概念，它可以決定Producer的訊息需要送往哪一個Queue。主要有四種模式：

• direct模式 ，可以直接將訊息丟給指定的Queue。
• topic模式 ，主題的概念，透過Binding規則，將訊息傳送給指定的Queue。
• header模式 ，藉由傳送資料的Header來指定訊息要送往的Queue。
• fanout模式 ，將訊息轉發給所有綁定到Exchange的Queue中。

5.綁定（Binding）， 搭配Exchange使用，可以讓Exchange綁定一些指定的Queue，從而知道Producer的訊息要送往何處。

以下圖 郵寄的例子 來說明，或許會稍微貼切一些：

日常生活中不免會遇到需要進行郵寄信件或包裹等業務，需要使用郵寄服務的寄件者會帶著包裹或信件至郵局進行投遞。 此時，郵局內部的人員可能會根據寄件者留下的 收件地址 （例如：收件地址位在中山區）將包裹或信件分派至該區域的郵局，最後透過分局將包裹或信件交付收件者。

RabbitMQ運行的種類/模式

1. Simple模式
   

   這是RabbitMQ中最簡單的模式，Producer,Consumer,Queue都只有一個。透過Producer直接將message傳進Queue中，最後由Consumer接收Queue中的訊息。

2. Worker模式
   

   由於Queue遵循先進先出演算法（FIFO）的概念，當Producer發送訊息的速度大於Consumer處理(消化)的速度時，這時simple模式如果被使用在 有時間限制的應用 上，就可會因為等待時間過長而導致任務失敗。

   相比Simple模式，Worker模式就能更有效的消化Queue中的訊息。Worker模式會有兩個以上的Consumer，同時從一個Queue中取出訊息，並且 兩者不會取出重複的訊息 。在默認情況下，RabbitMQ會以循環的方式，按照順序將訊息平均發送給每個Consumer。

   以生活中的例子來說 ，就像是大賣場中的收銀台，此時只有一個櫃員提供結帳服務，當越來越多顧客在排隊等候結帳時，櫃員就需要花更多時間消化掉這些顧客，而顧客也需要花更久的時間進行等待。 這時候賣場如果能夠加開多個櫃台提供結帳服務，就能夠更快速的處理這些顧客的結帳需求。

3. Publish/Subscribe模式
   

   與Work模式相比，多了交換機（Exchange）的機制，Producer會先將訊息交由交換機，再透過交換機將訊息傳送至指定的Queue中。

   交換機的模式承如先前介紹，包含了四種模式/類型（ direct, topic, headers, fanout ）。

   Exchange只負責轉發訊息而不具有儲存的功能，所以如果沒有任何的Queue與Exchange綁定，那訊息會遺失。

   比起前面所述的幾種模式，Publish/Subscribe模式類似於生活中的廣播/訂閱。在日常生活中，我們可能會訂閱一些Youtube頻道或新聞媒體等， 當該頻道發出新影片時，有訂閱的人就會收到上片通知，反之，沒有訂閱的人就不會收到消息。

4. Routing模式
   

   routing模式同樣也使用到Exchange，當Producer要將訊息交由交換機轉發時，需要在訊息上帶入一把RoutingKey，而Exchange會比對Queue的RoutingKey是否與訊息的RoutingKey一致，如果完全一致，交換機才會將訊息轉送至該Queue中。

   此外，routing模式具有多重綁定的功能，也就是說同一把Key可以綁到n個Queue中，而非一對一綁定。

5. Topics模式
   

   Topics模式也是Routing模式的一種，只是它的RoutingKey是採用 萬用字元的方式 與Queue進行匹配。另外，這種模式下交換機可以用 模糊匹配的方式 匹配到對應的Queue，再由監聽該Queue 的 Consumer 去消化裡面的訊息。

6. RPC模式
   

   就是透過Queue來實現遠端過程呼叫，Client端可以將定義好的訊息送至Queue中，再由Server端處理Queue中的訊息。 Client端為了獲得Server端處理後的結果，Client端會在向Server發送請求時，同時發送一個回調佇列（Callback queue）的地址（reply_to）， 用於告訴Server端，當處理完時該送回何處。

   在RPC模式下，Client端也可以同時發送多個訊息請求Server端進行處理。當Server端處理完後，為了讓Client端可以識別出Server端給予的回應， Client端在發送請求時，會附帶一個獨有的Correlation id，如此一來，Client端在回調佇列中就可以根據Correlation id辨識出這個回應是來自哪一個請求。